Determination of Interchange Categories

ABSTRACT

This document describes tools capable of auditing and/or determining reductions to card-issuer interchange fees charged for credit-card transactions. The tools may do so automatically and with user interaction for large amounts of transactions.

RELATED APPLICATION

This application is a divisional of and claims priority to U.S. patentapplication Ser. No. 11/740,143, filed on Apr. 25, 2007, entitled“Auditing or Determining Reductions to Card-Issuer Interchange Fees,”the disclosure of which is incorporated in its entirety by referenceherein.

BACKGROUND

In many typical credit-card transactions, a consumer purchases a productor service from a merchant using a VISA®- or MasterCard®-branded creditcard. To complete the transaction, the merchant receives anauthorization from a third party, known as a “merchant processor,” whichis sponsored by a VISA®- or MasterCard®-member bank. Merchants typicallyselect a merchant processor to install point-of-sale equipment, trainthe merchant's staff in the use of the equipment, access the credit-cardnetwork for authorizations, and process the merchant's credit-cardtransactions.

The merchant processor, through its sponsoring bank, reimburses themerchant for each transaction after deducting transaction fees retainedby the merchant processor. Within these transaction fees are themerchant processor's processing fee, the interchange fees paid to theissuer of the credit card, and the assessment fees that are paid to thecredit-card association. The merchant processor submits the nettransaction into the card association's settlement network in order tobe reimbursed by the issuing bank. The VISA® and MasterCard®associations are responsible for building, operating, maintaining,authorizing, and providing the information required for the member banksto settle their net transaction volume. Each association receives anassessment fee from both the merchant processor's bank and the issuer'sbank for each credit-card transaction processed through their respectivenetwork. The issuer in turn bills the consumer the full amount of theoriginal charge.

The interchange fees charged merchants by the card issuers can be quiteexpensive—currently billions of dollars a year worldwide. Unfortunately,the interchange categories used to determine these fees are difficult tounderstand and track, resulting in merchants paying much more than theyshould, either by not knowing how to change to less-expensiveinterchange categories or by being incorrectly assigned to expensiveinterchange categories.

These interchange categories are difficult to understand and track inpart because there are so many different kinds. Some are based on themerchant's retail industry status, some on the type of card presentedfor payment, and some on the process used by the merchant to gainauthorization for the transaction. For example, interchange categories(and thus the rate charged) may depend on whether the consumer's andcard's data is processed electronically from the magnetic strip on theback of the card, manually by the merchant based on the information setforth on the card, or manually by the merchant based on informationprovided by the consumer over the telephone. In short, the number andcomplexity of these categories make it difficult for a merchant toadequately track or reduce their interchange-category fees.

The effect of these interchange categories is also difficult to trackbecause of the sheer number of transactions received by merchants; somemerchants receive hundreds of thousands of transactions a month.Merchants simply do not have the extraordinary manpower or expertiseoften needed to audit these transactions or figure out how to changetransactions from an expensive category to a less-expensive category.

Further still, merchant processors—the companies that have goodinformation about categories and fees—often have no incentive to helpmerchants track and reduce these fees; most merchant processors make nomore money by providing details about these complexities than not doingso.

SUMMARY

This document describes tools capable of auditing and/or determiningreductions to card-issuer interchange fees charged for credit-cardtransactions. The tools may do so automatically and without userinteraction for large amounts of transactions.

This Summary is provided to introduce a selection of concepts in asimplified form that are further described below in the DetailedDescription. This Summary is not intended to identify key or essentialfeatures of the claimed subject matter, nor is it intended to be used asan aid in determining the scope of the claimed subject matter. The term“tools,” for instance, may refer to system(s), method(s),computer-readable instructions, and/or technique(s) as permitted by thecontext above and throughout the document.

BRIEF DESCRIPTION OF THE DRAWINGS

Non-limiting and non-exhaustive embodiments are described with referenceto the following figures, wherein like reference numerals refer to likeparts throughout the various views unless otherwise specified.

FIG. 1 illustrates an example operating environment in which variousembodiments of the tools may operate.

FIG. 2 illustrates an example flow diagram in which the tools act toenable the interchange module to receive credit-card transaction dataand other information.

FIG. 3 illustrates an example flow diagram in which the tools build andadjust a baseline interchange rate.

FIG. 4 illustrates an example flow diagram in which the tools determinea savings between an adjusted baseline interchange rate and a currentrate.

FIG. 5 illustrates an example flow diagram in which the tools auditinterchange categories assigned to credit-card transactions.

FIG. 6 illustrates an example process illustrating some ways in whichthe tools may act to audit and/or track fee reductions for interchangefees and their categories, as well as other actions.

DETAILED DESCRIPTION Overview

The following document describes tools capable of auditing and/ordetermining reductions to card-issuer interchange fees charged forcredit-card transactions. To audit these fees, the tools may receivedata indicating interchange categories assigned to various transactionsand determine—based on published merchant-status parameters for theassigned categories and a particular merchant's status—that the assignedinterchange categories are or are not correct. The tools may also trackreductions to these fees for a client, including by building a baselinerate for the client over a period of time and then adjusting that rateto reflect interchange rate changes. After informing the client of waysin which to reduce their interchange fees, the tools may automaticallytrack credit-card transaction data to determine rate reductions andsavings for ongoing billing cycles.

An environment in which the tools may enable these and other actions isset forth below in a section entitled Example Operating Environment.This section is followed by Storing Credit-Card Transaction Data, whichdescribes one particular example in which the tools act to enable aninterchange module to receive credit-card transaction data and performother actions for a national bookstore chain. The next section, entitledBuilding and Adjusting Baseline Interchange Rates, continues thebookstore example in the context of building and adjusting a baselineinterchange rate for the national bookstore chain. The following sectioncontinues the bookstore example and determines a savings between anadjusted baseline interchange rate and a current rate; it is entitledDetermining Card-Issuer Interchange-Fee Savings. The next section,entitled Auditing Interchange Categories, continues the example but fromthe Storing section, and describes ways in which the tools auditinterchange categories assigned to credit-card transactions. A finalsection describes various other embodiments and manners in which thetools may act and is entitled Other Embodiments of the Tools. Thisoverview, including these section titles and summaries, is provided forthe reader's convenience and is not intended to limit the scope of theclaims or the entitled sections.

Example Operating Environment

Before describing the tools in detail, the following discussion of anexample operating environment is provided to assist the reader inunderstanding some ways in which various inventive aspects of the toolsmay be employed. The environment described below constitutes but oneexample and is not intended to limit application of the tools to any oneparticular operating environment. Other environments may be used withoutdeparting from the spirit and scope of the claimed subject matter.

FIG. 1 illustrates one such operating environment generally at 100having data sources 102, a data-entry entity 104, a relational database106, and a computing device 108. Communications between these entitiesare shown with arrows.

The data sources may include text-formatted documents easily readable byhumans (e.g., paper), websites, or accessible databases, to name a few.The data-entry entity is responsible for retrieving information from thedata sources and storing it in the relational database. This entity mayinclude a person reading information from a paper document or websiteand typing the information into an application through which informationis stored in intermediate memory or directly into the relationaldatabase, an application using Application Program Interfaces (APIs) toaccess API-accessible databases or applications and store information,or a Bot (an Internet-searching data gatherer) capable of gleaninginformation from websites and other data sources over the Internet. Thisentity may store information automatically and/or without userinteraction in many cases, such as when it includes an application usingAPIs or a Bot.

The relational database includes one or more databases in which data maybe stored and from which data may be extracted, such as a SQL™, Oracle™,or IBM™ DB2 relational database.

The computing device includes one or more processor(s) 110 andcomputer-readable media 112. The computing device is shown with a servericon, though it may comprise one or multiple computing devices ofvarious types. The processors are capable of accessing and/or executingthe computer-readable media.

The computer-readable media includes or has access to a formattingmodule 114, an interchange module 116, and a report generator module118. In many cases credit-card transaction data is provided in a formator formats that are not easily readable by the interchange module or arenot consistent. In these cases the formatting module may transform theinformation into one, easily-machine-usable format, often prior toloading it into the relational database. In one example case describedin greater detail below, the formatting module includes an executableExtract, Transform, and Load (ETL) package. This ETL package may extracthuman-readable, text-formatted (e.g., pre-transformed) credit-cardtransaction data of one or multiple formats, transform this data into aformat easily-usable by the interchange module, and load it into therational database in a standardized format that may be used forcomputation.

The interchange module is capable of auditing and/or tracking reductionsto interchange fees charged to merchants incident to those merchantsaccepting payments with credit cards. Note that the term “credit”includes credit, debit, and other accounting systems so long as they areprocessed by a credit or debit association (e.g., VISA® andMasterCard®). Also note that the term “card” applies to any medium ormanner in which sales or purchases may be electronically transacted,such as a card having a magnetic strip, a card having circuitry, acredit account not having any physical element, or a key-faub thatelectromagnetically identifies an account. Ways in which the interchangemodule may audit and/or track fee reductions are developed in greaterdetail below.

The report generator module is capable of receiving information from theinterchange module and providing reports on this information in human orcomputer-readable formats.

Generally, any of the functions described herein can be implementedusing software, firmware, hardware (e.g., fixed logic circuitry), or acombination of these implementations. The terms “module,”“functionality,” “tools,” and “logic” as used herein generally representsoftware, firmware, hardware, or a combination thereof. In the case of asoftware implementation, the module, functionality, tools, or logicrepresents program code that performs specified tasks when executed on aprocessor (e.g., CPU or CPUs). The program code can be stored in one ormore computer readable memory devices. The features of the techniquesdescribed below are platform-independent, meaning that the techniquesmay be implemented on a variety of commercial computing platforms havinga variety of processors.

For example, the computing device 108 may also include an entity (e.g.,software) that causes hardware of the computing device 108 to performoperations, e.g., processors, functional blocks, and so on. For example,the computing device 108 may include a computer-readable medium that maybe configured to maintain instructions that cause the computing device,and more particularly hardware of the computing device 108 to performoperations. Thus, the instructions function to configure the hardware toperform the operations and in this way result in transformation of thehardware to perform functions. The instructions may be provided by thecomputer-readable medium to the computing device 108 through a varietyof different configurations.

One such configuration of a computer-readable medium is signal bearingmedium and thus is configured to transmit the instructions (e.g., as acarrier wave) to the hardware of the computing device, such as via anetwork. The computer-readable medium may also be configured as acomputer-readable storage medium and thus is not a signal bearing mediumor transitory media. Examples of a computer-readable storage mediuminclude a random-access memory (RAM), read-only memory (ROM), an opticaldisc, flash memory, hard disk memory, and other memory devices that mayuse magnetic, optical, and other techniques to store instructions andother data.

Storing Credit-Card Transaction Data

This section describes one particular example in which the tools act tostore credit-card transaction data and enable the interchange module toreceive this data. This example is an implementation of the tools but isnot intended to limit the scope of the tools or the claimed embodiments.

The credit-card transaction data that the tools enable the interchangemodule to receive includes information about credit-card transactions(e.g., customers purchasing a product or service from a merchant using acredit card). This credit-card transaction data may include, for eachpurchase or groups of purchases, the purchase price, the date of thepurchase or date that the purchase was batched by the merchant, acard-issuer interchange category, fee, or rate for the purchase, andthrough which credit-card association's network the purchase was made(e.g., VISA® or MasterCard®). The data may also indicate each purchaseand its interchange category or groups of purchases by their interchangecategory, such as those categorized as VISA® Business Select, VISA®Business Standard, VISA® Standard, VISA®, RTL CK DB, VISA® CPS Retail,VISA® Credit Consumer Card, VISA® Credit Commercial Card, VISA® EIRF DB,VISA® Standard DB, VISA® CV-CN SR DB, VISA® Dues and Assessments,MasterCard® Standard, MasterCard® Merit, MasterCard® Key Entered,MasterCard® Corporate Data RTI, MasterCard® Standard DB, MasterCard® KeyEntered DB, MasterCard® Merit 3 DB, MasterCard® Cons DB RF 3,MasterCard® Cons CR RF 4, MasterCard® Corporate CR RF 3, and MasterCard®Dues and Assessments, to name a few.

Parameters used to determine the category may also be included in thecredit-card transaction data, such as a transaction's merchant's statusparameters: business sector; area of operation; and taxable ornon-taxable status, and parameters specific to the transaction, such as:having or not having the credit card present at the time of purchase;having the purchase made over the Internet or a telephone; having anaddress for the customer included with the transaction; and having asignature of the customer.

Having described the credit-card transaction data in some detail, theexample turns to FIG. 2. FIG. 2 shows actions and interactions of andbetween elements of operating environment 100 of FIG. 1, as well as someresults of these actions and interactions.

At arrow 2-1 in FIG. 2, a Bot 202 included in data-entry entity 104gleans credit-card transaction data from a merchant processor's website102 w. Merchant processors often present credit-card transaction data tomerchants on a website in a human-readable text format. Note that theBot may glean credit-card transaction data for many if not thousands ofmerchants automatically and without user interaction throughmerchant-processors websites. In this example the data-entry entitygleans credit-card transaction data for all merchants associated with aparticular client—here a national bookstore chain. A client may have onemerchant or may have hundreds or thousands, depending on the size of thebusiness.

The example national bookstore chain is assumed to have, for eachbookstore, a merchant at its coffee shop, merchants at its check-outline, and a merchant at its service counter. This national bookstorealso has merchants accessible through the Internet for websitepurchases. Assume that the national bookstore has 200 stores and 2,000merchants. Each of the merchants may have hundreds or thousands ofcredit-card transaction per billing period, amounting to 800,000 to8,000,000 credit-card transactions per billing period (e.g., a calendarmonth). As this number suggests, it is difficult if not impossible forclients to keep track of all credit-card transactions in a billingperiod by reading merchant-processor statements on websites, on paper,or in human-readable text formats.

Consider the following example merchant-processor statement inhuman-readable text format. This processor statement is presented at themerchant processor's website 102 w of FIG. 2. This statement includescredit-card transaction data for just one merchant during just onebilling cycle.

5/31/2005  1923    1923920009 Merchant Processor Merchant Processor'sAddress Merchant Processor's Identification Number Merchant Merchant'sAddress Merchant's Identification Number: 932734932 PLAN SUMMARY PL #SALES $ SALES # CREDITS $ CREDITS NET SALES AVG TKT DISC P/I % DISCOUNTDUE V 997 52,203.43 26 925.68 51,277.75 52.36 .130 .000 129.61 M 157477,488.14 40 1,180.06 76,308.08 49.23 .130 .000 204.62 DS 298 16,210.9917 583.77 15,627.22 54.40 .000 .000 .00 ** 2869 145,902.56 83 2,689.51143,213.05 50.85 334.23 DAY REF NO. * PL #SALES $SALES $CREDITS DIS.PDNET DEPOSIT 01 52106000034 D T 76 3,695.36 136.59 .00 3,558.77 0252106100038 D T 73 4,028.78 39.33 .00 3,989.45 03 52106200038 D T 644,709.22 .00 .00 4,709.22 04 52106300037 D T 95 4,131.47 87.09 .004,044.38 06 52106400038 D T 97 4,440.53 119.75 .00 4,320.78 0652106500036 D T 149 9,125.75 84.94 .00 9,040.81 07 52106600038 D T 632,500.94 57.31 .00 2,443.63 08 52106700037 D T 92 4,395.07 150.35 .004,244.72 09 52106800038 D T 77 3,466.22 54.15 .00 3,412.07 1052106900038 D T 78 3,445.58 18.05 .00 3,427.53 11 52107000037 D T 873,442.54 65.83 .00 3,376.71 13 52107100037 D T 87 4,151.55 358.95 .003,792.60 13 52107200037 D T 117 6,766.41 5.29 .00 6,761.12 1452107300036 D T 88 4,406.70 63.72 .00 4,342.98 15 52107400038 D T 762,070.91 35.54 .00 2,035.37 16 52107500038 D T 94 4,606.75 62.78 .004,543.97 17 52107600036 D T 90 3,568.66 7.43 .00 3,561.23 18 52107700040D T 122 5,764.02 174.37 .00 5,589.65 20 52107800038 D T 119 5,803.9744.70 .00 5,759.27 21 52108000039 D T 230 15,854.65 32.97 .00 15,821.6822 52108100040 D T 111 5,544.80 232.06 .00 5,312.74 23 52108200037 D T93 4,199.12 141.67 .00 4,057.45 24 52108300040 D T 76 2,660.72 128.79.00 2,531.93 25 52108400038 D T 71 2,764.74 12.74 .00 2,752.00 2752108500040 D T 112 7,216.82 39.55 .00 7,177.27 27 52108600038 D T 1347,511.06 219.85 .00 7,291.21 29 52108800040 D T 107 5,101.36 134.45 .004,966.91 31 52109000040 D T 191 10,528.86 181.26 .00 10,347.60 DEPOSITTOTALS 2,869 145,902.56 2,689.51 .00 143,213.05 AMOUNT DEDUCTED FROMACCOUNT 2,725.61 FEES NUMBER AMOUNT DESCRIPTION TOTAL SUPPORT PACKAGE5.95 02 14.00 TERMINAL FEE 28.00 10 586.95 VISA ® STANDARD (2.63%XSALES + $.10XITEMS) 16.44 350  12,452.24 VISA ® RTL CK DB (1.05%XSALES + $.15XITEMS) 183.25 461  27,404.65 VISA ® CPS RETAIL (1.54%XSALES + $.10XITEMS) 468.13 57 3,431.71 VISA ® EIRF (2.14% XSALES +$.10XITEMS) 79.14   16- 662.12- VISA ® CREDIT CONSUMER CARD @ 1.67%11.06-   01- 6.37- VISA ® CREDIT COMMERCIAL CARD @ 2.24% .14- 471,716.92 VISA ® EIRF DB (1.75% XSALES + $.20XITEMS) 39.45 02 92.90VISA ® STANDARD DB(1.90% XSALES + $.25XITEMS) 2.27   09- 257.19- VISA ®CV-CNSR DB (1.31% XSALES) 3.37- 52,203.43 VISA ® DUES AND ASSESSMENTS(.0925% XSALES) 48.29 10 1,577.69 MC STANDARD (2.70% XSALES +$.10XITEMS) 43.60 522  32,284.36 MC MERIT 3 (1.54% XSALES + $.10XITEMS)549.38 06 1,579.45 MC KEY ENTERED (1.90% XSALES + $.10XITEMS) 30.61 813,821.95 MC CORP DATA RT1(2.65% XSALES + $.10XITEMS) 109.38 16 604.03 MCSTANDARD DB (1.90% XSALES + $.25XITEMS) 15.48 10 203.57 MC KEY ENTER DB(1.64% XSALES + $.16XITEMS) 4.94 929  37,417.09 MC MERIT 3 DB (1.05%XSALES + $.15XITEMS) 532.23   19- 371.74- MC CONS DB RF 3 @1.40% 5.20-  19- 668.64- MC CONS CR RF 4 @1.77% 11.83-   02- 139.68- MC CORP CR RF3 @2.15% 3.00- 77,488.14 MC DUES AND ASSESSMENTS(.095% XSALES) 73.61 656,311.88 VISA ® BUS ELECT (2.20% XSALES + $.10XITEMS) 145.36 05 206.18VISA ® BUS STD (2.70% XSALES + $.10XITEMS) 6.07 296  DISCOVERAUTHORIZATIONS @ 15 CENTS 44.40 OTHER FEES DUE 2,391.38 DISCOUNT DUE334.23 OTHER FEES DUE 2,391.38 AMOUNT DEDUCTED 2,725.61 Legend CARD PLANCODES VD—VISA ® DEBIT CARD VB—VISA ® BUSINESS CARD M—MASTERCARD ®MB—MASTERCARD ® BUS. CARD P1—PRIVATE LABEL PLAN 1 P2—PRIVATE LABEL PLAN2 P3—PRIVATE LABEL PLAN 3 VA—VISA ® CASH MA—MASTERCARD ® CASH VL—VISA ®LARGE TICKET ML—MCS LARGE TICKET DB—DEBIT CARD JB—JCB DC—DINERS CLUBCARD DS—DISCOVER AM—AMERICAN EXPRESS V—VISA ® TRANSACTION PLAN CODESV—VISA ® M—MASTERCARD ® P—PRIVATE LABEL L—LARGE TICKET T—ALL PLANS1—PLAN ONE 2—PLAN TWO 3—PLAN THREE A—CASH ADVANCE D—DEBIT B—BUSINESSCARD TRANSACTION TYPE CODES D—DEPOSIT C—CHARGEBACK A—ADJUSTMENTB—CHARGEBACK REVERSAL

At arrow 2-2, the data-entry entity stores the credit-card transactiondata into intermediate storage 204 in the human-readable text format.The data stored in this example is human-readable text and likelydiffers from a format of some other merchant or client or is not aneasily-machine-usable format. The tools proceed to arrow 2-3 to addressthis issue.

At arrow 2-3, formatting module 114 extracts the text-format credit-cardtransaction data for the thousands of merchants of the nationalbookstore chain using an Extract portion of an Extract, Transform, andLoad (ETL) process. The tools execute a formatting ETL package 206,shown included in the formatting module of FIG. 2, to perform this ETLprocess. The formatting module differentiates between merchants of thenational bookstore chain and other merchants based on merchantidentifiers associated with the bookstore. These merchant identifiersare stored in table 208 in the relational database.

At arrow 2-4, the formatting module transforms the text-format creditcard transaction data into an easily-machine-usable format for thethousands of merchants and uses a Transform portion of the ETL process.This transformation is shown with arrow 2-4.

At arrow 2-5, the formatting module loads the credit-card transactiondata in the easily-machine-usable format into the relational database.It loads the credit-card transaction data in this easily-machine-usableformat for the thousands of merchants using a Load portion of the ETLprocess. For the one example merchant above, the formatting modulestores its data into table 208 of the rational database. The formattingmodule also associates the merchant identifiers (here the “Merchant'sIdentification Number”) in table 208 with the appropriate credit-cardtransaction data. The formatting module may also or instead associatethe credit-card transaction data with internal database record numbers.

At this point in the process, credit-card transaction data is stored inthe relational database in a format that is easily usable andconsistent. By so doing, interchange module 116 may use the data toaudit, track fee reductions, or otherwise use information aboutinterchange categories for credit-card transactions. Examples of how theinterchange module may do so are described below and include building abaseline card-issuer interchange rate and adjusting that rate, auditingcard-issuer interchange fees, and tracking reductions in those fees.

Building and Adjusting Baseline Interchange Rates

This section continues the above example in the context of credit-cardtransaction data being made available to interchange module 116 to buildand adjust a baseline interchange rate for the above-described nationalbookstore chain. In later sections the transaction data made availableto the interchange module will be used for other purposes, such asmonthly auditing or determining savings.

In this section the tools start by building, automatically and withoutuser interaction, a baseline interchange rate for the bookstore clientbased on a twelve-month history of credit-card transaction data for thebookstore's 2,000 merchants. The interchange module is enabled toextract this historical data by the tools performing the actions of FIG.2 twelve times for each of the 2,000 merchants, i.e., for 24,000merchant-processor statements.

The credit-card transaction data received is in an easily-machine-usableform and includes card-issuer interchange fees, dollar volumes, andnumbers of transactions to which card-issuer interchange categories areassigned by a merchant processor. This data is for each merchant and foreach billing cycle of the historic period, i.e., twelve historicmerchant-processor statements of each particular merchant for all of thebookstore's merchants over the historical twelve-month period.

Specially, at arrow 3-1 in FIG. 3, interchange module 116 extractscard-issuer interchange fees and dollar volumes on which the fees wereassessed for all of the bookstore's 2,000 merchants over the last twelvebilling cycles. The interchange module uses each merchant's identifier(e.g., “932734932”) and each billing cycle's end date (e.g., May31^(st), 2005) to find this information in relational database 106(e.g., portions of table 208 for one merchant at one billing cycle).

At arrow 3-2, the interchange module adds up all the fees and dollarvolumes for each merchant over the twelve-month period. The interchangemodule then does this again and again for every merchant and then addsthese together. By so doing, the interchange module determines theclient's total fees and dollar volume on which the fees were based.

At arrow 3-3, the interchange module divides the total fees by thisdollar volume to provide a baseline card-issuer interchange rate for thehistorical twelve-month period for the bookstore.

At arrow 3-4, the interchange module loads the baseline card-issuerinterchange rate into relational database 106. The interchange moduleperforms the actions of arrows 3-1 to 3-4 using baseline ETL package302, shown included in interchange module 116 in FIG. 3.

After building the baseline, the tools proceed to adjust the baseline inthe following example manner.

At arrow 3-5, the interchange module determines the dollar volume onwhich each card-issuer interchange category was assigned for allcredit-card transactions for all of the bookstore's 2,000 merchantsduring the historic period. The categories assigned may be tracked aspart of arrows 3-1 to 3-3 or separately, as is done here. Here theinterchange module extracts, from the historic credit-card transactiondata for the bookstore's merchants, the interchange categories assigned,the dollar volumes, and the number of transactions for each of theinterchange categories. Consider a portion of the examplemerchant-processor statement provided above:

FEES NUMBER AMOUNT DESCRIPTION TOTAL SUPPORT PACKAGE 5.95 02 14.00TERMINAL FEE 28.00 10 586.95 VISA ® STANDARD (2.63%XSALES + $.10XITEMS)16.44 350  12,452.24 VISA ® RTL CK DB (1.05%XSALES + $.15XITEMS) 183.25461  27,404.65 VISA ® CPS RETAIL (1.54%XSALES + $.10XITEMS) 468.13 573,431.71 VISA ® EIRF (2.14%XSALES + $.10XITEMS) 79.14   16- 662.12−VISA ® CREDIT CONSUMER CARD @ 1.67% 11.06−   01- 6.37− VISA ® CREDITCOMMERCIAL CARD @ 2.24% .14− 47 1,716.92 VISA ® EIRF DB (1.75%XSALES +$.20XITEMS) 39.45 02 92.90 VISA ® STANDARD DB(1.90%XSALES + $.25XITEMS)2.27   09- 257.19− VISA ® CV-CNSR DB (1.31%XSALES) 3.37− 52,203.43VISA ® DUES AND ASSESSMENTS (.0925%XSALES) 48.29 10 1,577.69 MC STANDARD(2.70%XSALES + $.10XITEMS) 43.60 522  32,284.36 MC MERIT 3(1.54%XSALES + $.10XITEMS) 549.38 06 1,579.45 MC KEY ENTERED(1.90%XSALES + $.10XITEMS) 30.61 81 3,821.95 MC CORP DATART1(2.65%XSALES + $.10XITEMS) 109.38 16 604.03 MC STANDARD DB(1.90%XSALES + $.25XITEMS) 15.48 10 203.57 MC KEY ENTER DB(1.64%XSALES + $.16XITEMS) 4.94 929  37,417.09 MC MERIT 3 DB(1.05%XSALES + $.15XITEMS) 532.23   19- 371.74− MC CONS DB RF 3 @1.40%5.20−   19- 668.64− MC CONS CR RF 4 @1.77% 11.83−   02- 139.68− MC CORPCR RF 3 @2.15% 3.00− 77,488.14 MC DUES AND ASSESSMENTS(.095%XSALES)73.61 65 6,311.88 VISA ® BUS ELECT (2.20%XSALES + $.10XITEMS) 145.36 05206.18 VISA ® BUS STD (2.70%XSALES + $.10XITEMS) 6.07 296  DISCOVERAUTHORIZATIONS @ 15 CENTS 44.40 OTHER FEES DUE 2,391.38

In this case the interchange module determines that 461 credit-cardtransactions totaling $27,404.65 were assigned a “VISA® CPS RETAIL”card-issuer interchange category for one merchant for one billing cycle.The interchange module does this over and over for each category andeach merchant and each billing cycle in the historic period. Assume, forexample, that the interchange module determines that 800,000transactions totaling $50,000,000 were assigned a “VISA® CPS RETAIL”category for the bookstore during the twelve-month history.

At arrow 3-6, the interchange module receives current card-issuerinterchange rates for each of the categories assigned to a credit-cardtransaction. The module receives this by extracting it from therelational database into which it was stored by data-entry entity 104either automatically or by manual user entry.

At arrow 3-7, the interchange module determines if any of the assignedcategory's rates have changed. Assume that the “VISA® CPS RETAIL” rate,which during the historic period was 1.54% of each sale plus $0.10 persale, is now 1.55% of each sale plus $0.11 per sale. For simplicity,assume that no other category's rate has changed since or during thetwelve-month historical period (which is unlikely). The interchangemodule determines that the “VISA® CPS RETAIL” rate changed based on itsold rate (which was found in the credit-card transaction data in themerchant-processor statement but could be found in other ways) comparedto the new rate.

At arrow 3-8, the interchange module determines the rate change—here0.01% of each sale and $0.01 per sale.

At arrow 3-9, the interchange module determines a fee difference overthe historical period sufficient to reflect the rate change. This ratechange reflects what the baseline rate would have been had the new ratebeen charged throughout the historic period. The interchange modulemultiplies the rate change by the dollar volume and number oftransactions.

The “VISA® CPS RETAIL” category had 800,000 transactions totaling$50,000,000, so the fee difference is:

Fee difference=0.0001×$50,000,000+$0.01×800,000=$13,000

At arrow 3-10, the interchange module adds this fee to the total fee forall credit-card transactions for the bookstore during the historicalperiod. Here assume the total fee was $15,000,000. Thus, the adjustedfee over the baseline historical period would be $15,013,000.

At arrow 3-11, the interchange module divides the adjusted fee of$15,013,000 by the total dollar volume for the bookstore over thehistorical period (e.g., $750,000,000). This provides an adjustedbaseline card-issuer interchange rate. If the fee based on the adjustedrate was $15,000,000 divided by $750,000,000, and thus 2.00%, theadjusted baseline rate is 2.00173333%.

At arrow 3-12, the interchange module stores the adjusted baseline ratein relational database 106 of FIG. 3. The interchange module may performthe actions of arrows 3-5 to 3-11 using a Transform portion of an ETLprocess by executing baseline ETL package 302 and arrow 3-12 using aLoad portion of this ETL process.

At this point various potential fee savings may be proposed, such asways to upgrade some types of future transactions from unfavorable(expensive) categories to more-favorable (less-expensive) categories.VISA® EIRF DB, for example, which is currently at a 2.14% fee, may beupgraded to VSIA CPS Retail (currently 1.54%) by changing order-intakeprocedures. The bookstore can changes its policies to upgrade orotherwise avoid high-fee interchange categories being assigned tocredit-card transactions. The tools determine fees saved based on theseand other changes by comparing the adjusted baseline card-issuerinterchange rate for the client with a current rate being assessed. Oneway in which to find these savings is described in the followingsection.

Determining Card-Issuer Interchange-Fee Savings

This section continues the above example in the context of credit-cardtransaction data being made available to interchange module 116 todetermine a savings between an adjusted baseline interchange rate and acurrent rate. This data is made available following its being providedin FIG. 2, only in this section the interchange module determines acurrent rate rather than a baseline rate.

At arrow 4-1 in FIG. 4, interchange module 116 extracts card-issuerinterchange fees and dollar volumes on which the fees were assessed forall of the bookstore's 2,000 merchants over a current billing cycle. Theinterchange module uses each merchant's identifier (e.g., “932734932”)and each billing cycle's end date (e.g., Apr. 30, 2007) to find thisinformation in relational database 106. Consider a portion of amerchant-processor statement for the current billing period and for thesame merchant described in FIGS. 2 and 3 above.

FEES NUMBER AMOUNT DESCRIPTION TOTAL SUPPORT PACKAGE 5.95 02 14.00TERMINAL FEE 28.00 04 80.11 VISA ® STANDARD (2.63%XSALES + $.10XITEMS)2.50 . . . 297 DISCOVER AUTHORIZATIONS @ 15 CENTS 44.55 OTHER FEES DUE1,991.20 DISCOUNT DUE 304.23 OTHER FEES DUE 1,991.20

At arrow 4-2, the interchange module adds up all the fees and dollarvolumes on which interchange fees are charged for each merchant over thecurrent billing cycle. Here the “Discover Authorization” fees and theterminal fees are excluded, as they are not an amount on which acard-issuer interchange fee is charged.

Thus, interchange fees for the particular merchant during the currentbilling cycle are:

Interchange Fees=$1,991.20−28.00−44.55=$1,918.65

The interchange module does this again for every merchant. By so doing,the interchange module determines the client's total fees and dollarvolume on which the interchange fees were based for the current billingcycle.

At arrow 4-3, the interchange module divides the total interchange feesby this dollar volume to provide a current card-issuer interchange ratefor the current billing cycle for the bookstore. For the particularmerchant above, assume that the interchange dollar volume is$148,411.43. Thus, the current card-issuer interchange rate is:

Merchant's Current Rate=$1,918.65/$148,411.43=1.29%

For the bookstore, assume that the current total interchange fees are$598,000 and total dollar volume on which these fees were charged is$31,000,000. The bookstore's current card-issuer interchange rate is:

Bookstore's Current Rate=$598,000/$31,000,000=1.93%

At arrow 4-4, the interchange module determines a rate differencebetween the bookstore's current rate and the bookstore's adjustedbaseline card-issuer interchange rate by subtracting the current ratefrom the adjusted rate. The bookstore's rate difference is:

Bookstore's Rate Difference=2.00173333%−1.93%=0.0717333%

At arrow 4-5, the interchange module determines the interchange feesavings by multiplying the bookstore's rate difference by its dollarvolume on which interchange fees were applied. The savings are:

Bookstore's Savings=$31,000,000×0.0717333%=$22,237.32

At arrow 4-6, the interchange module provides the bookstore's savings toreport generator module 118. The report generator module receives thesavings and generates a report that is human readable, shown at arrow4-7 and with report 402. This report may be a window on a computerscreen (e.g., a graphical user interface) or a PDF file for reading on acomputer screen or printing and viewing on paper. This report generatormay also, in conjunction with the interchange module or independently,multiply the savings by a particular percentage, such as onecontractually agreed-on by the client (e.g., the bookstore) and the userof the interchange module to assess a payment for services rendered inreducing interchange fees.

The interchange module performs the actions of arrows 4-1 to 4-5 using asavings ETL package 404, shown included in the interchange module inFIG. 4. The act of extracting card-issuer interchange fees and dollarvolumes of arrow 4-1 is performed by an Extract portion of an ETLprocess caused by the computing device executing the savings ETLpackage. The acts of adding up all the fees and dollar volumes, dividingthe total interchange fees by this dollar volume, subtracting thecurrent rate from the adjusted rate, and multiplying the bookstore'srate difference by its dollar volume on which interchange fees wereapplied, at arrows 4-2, 4-3, 4-4, and 4-5, respectively, are performedby a Transform portion of this ETL process. The saving ETL package alsoprovides the bookstore's savings to the report generator module asdescribed at arrow 4-6 using a Load portion of the ETL process.

Auditing Interchange Categories

This section sets forth one example way in which the tools auditinterchange categories assigned to credit-card transactions. Itcontinues the example of the bookstore, but may be separate from orintegral with the Building and Adjusting Baseline Interchange Rates andDetermining Card-Issuer Interchange-Fee Savings sections.

In this example, interchange module 116 determines, automatically andwithout user interaction, whether interchange categories assigned to amerchant's credit-card transactions are correct. The interchange module,in conjunction with other elements of exemplary embodiment 100, candetermine whether hundreds of thousands of credit-card transactions orgroups of transactions were assigned a correct interchange category.

Turning to FIG. 5, at arrow 5-1 the interchange module receivespublished interchange-category parameters for each of the interchangecategories assigned to a particular merchant and to which credit-cardtransactions were assigned or may potentially be correctly assigned.These parameters may change over time, so the interchange modulereceives parameters used for a particular billing cycle in which thecredit-card transactions were transacted or batched. These publishedparameters include, by way of example, the following merchant-statusinterchange parameters: business sector; area of operation; and taxableor non-taxable status. A (fictitious) VISA® Education interchangecategory, for example, may include a published interchange-categoryparameter requiring that the merchant receiving the credit-cardtransaction be in an education business section and have a non-taxablestatus.

These published interchange-category parameters are published by thecard issuer of that interchange category, such as VISA® or MasterCard®.They may be published on a website, made available through APIs, ordistributed to interested parties in electronic or paper form. In anycase, these published interchange-category parameters are entered intorelational database by data-entry entity 104 in any of the mannersdescribed above for entering data (not shown in FIG. 5).

At arrow 5-2, the interchange module receives a merchant'sinterchange-category parameters. Continuing the bookstore example,assume that the interchange module receives interchange-categoryparameters for all of the bookstore's merchants and that one of itsmerchants is in an education business section but has a taxable status(e.g., a for-profit text-book store owned by the national bookstorechain). These parameters are received by the interchange module from therelational database after being stored in the database by data-entryentity 104 either manually or electronically.

At arrow 5-3, the interchange module receives credit-card transactiondata indicating groups of credit-card transactions and their assignedinterchange categories. Assume that the merchant at issue is thefor-profit text-book store owned by the national bookstore chain.

Consider the following groups of transactions and their assignedinterchange categories for this text-book store:

FEES NUMBER AMOUNT DESCRIPTION TOTAL SUPPORT PACKAGE 5.95 02 14.00TERMINAL FEE 28.00 10 586.95 VISA ® STANDARD (2.63%XSALES + $.10XITEMS)16.44 350  12,452.24 VISA ® RTL CK DB (1.05%XSALES + $.15XITEMS) 183.25461  27,404.65 VISA ® CPS RETAIL (1.54%XSALES + $.10XITEMS) 468.13 573,431.71 VISA ® EDUCATION (2.14%XSALES + $.10XITEMS) 79.14   16- 662.12−VISA ® CREDIT CONSUMER CARD @ 1.67% 11.06−   01- 6.37− VISA ® CREDITCOMMERCIAL CARD @ 2.24% .14− 47 1,716.92 VISA ® EIRF DB (1.75%XSALES +$.20XITEMS) 39.45 02 92.90 VISA ® STANDARD DB(1.90%XSALES + $.25XITEMS)2.27   09- 257.19− VISA ® CV-CNSR DB (1.31%XSALES) 3.37− 52,203.43VISA ® DUES AND ASSESSMENTS (.0925%XSALES) 48.29 10 1,577.69 MC STANDARD(2.70%XSALES + $.10XITEMS) 43.60 522  32,284.36 MC MERIT 3(1.54%XSALES + $.10XITEMS) 549.38 06 1,579.45 MC KEY ENTERED(1.90%XSALES + $.10XITEMS) 30.61 81 3,821.95 MC CORP DATART1(2.65%XSALES + $.10XITEMS) 109.38 16 604.03 MC STANDARD DB(1.90%XSALES + $.25XITEMS) 15.48 10 203.57 MC KEY ENTER DB(1.64%XSALES + $.16XITEMS) 4.94 929  37,417.09 MC MERIT 3 DB(1.05%XSALES + $.15XITEMS) 532.23   19- 371.74− MC CONS DB RF 3 @1.40%5.20−   19- 668.64− MC CONS CR RF 4 @1.77% 11.83−   02- 139.68− MC CORPCR RF 3 @2.15% 3.00− 77,488.14 MC DUES AND ASSESSMENTS(.095%XSALES)73.61 65 6,311.88 VISA ® BUS ELECT (2.20%XSALES + $.10XITEMS) 145.36 05206.18 VISA ® BUS STD (2.70%XSALES + $.10XITEMS) 6.07 296  DISCOVERAUTHORIZATIONS @ 15 CENTS 44.40 OTHER FEES DUE 2,391.38 Note the boldedgroup of credit-card transactions and their category: VISA ® Education(provided for example purposes - not a currently-used category). Asnoted above, this category requires that the merchant receiving thecredit-card transaction be non-taxable and in the education businesssector.

At this point the interchange module has the following information: thepublished interchange-category parameters for VISA® Education; theinterchange-category parameters for the text-book store; and that agroup of transactions have been assigned this VISA® Education category.The interchange module also has credit-card transaction data about thisgroup of transactions: the number of transactions; amount of thetransactions; and amount of the interchange fee charged.

At arrow 5-4, the interchange module determines whether or not theinterchange categories assigned to all transactions and for all of theclient's merchants during a billing cycle are correct. Continuing thisexample, the interchange module compares the interchange-categoryparameters for the text-book store with those required for the VISA®Education interchange category. The VISA® Education interchange categoryrequires that the merchant have a non-taxable status. Here the text-bookstore is for-profit and so has a taxable status. Thus, the interchangemodule determines that the group of transactions assigned the VISA®Education interchange category were incorrectly assigned this category.

For each transaction or group of transactions that are correctlyassigned, the interchange module records this finding in the relationaldatabase. For each transaction or group of transactions that are notcorrectly assigned, the interchange module can proceed to indicate thisfinding and the other pertinent information (the merchant, the reasonthe assigned category was incorrect, and credit-card transaction dataabout the transaction(s)) to report generator module 118 at arrow 5-5,or continue first to 5-6 to compute a savings or loss.

At arrow 5-6, the interchange module determines the correct interchangecategory based on comparing published interchange-category parametersfor various interchange categories with the interchange-categoryparameters for the merchant.

For the VISA® Education group of transactions the interchange moduledetermines that VISA® EIRF DB is correct because VISA® EIRF DB appliesto merchants with a taxable status with an education business section(and others), and because the transactions were handled in a particularmanner (i.e., following EIRF DB's requirements).

At arrow 5-7, the interchange module determines the correctinterchange-category fee that should have been charged. Here EIRF DBshould have been applied instead of Education. VISA® Education's fee is2.14% times the amount plus $0.10 per transaction, with a charged fee of$79.14. The interchange module determines the correct fee, which forVISA® EIRF DB is:

VISA® EIRF DB=1.75%×Sales+$0.20×Items

For the group at issue, this computes to:

VISA® EIRF DB=1.75%×$3,431.71+$0.20×57=$60.05+$11.40=$71.45

At arrow 5-8, the interchange module determines the savings or loss,here:

Savings=$79.14−$71.45=$7.69

Following arrow 5-8, the interchange module sends this savingsinformation to the report-generator module according to arrow 5-5.

The interchange module performs the actions of arrows 5-1 to 5-8 usingan Audit ETL package 502, shown included in the interchange module inFIG. 5. The acts of arrows 5-1, 5-2, and 5-3 by an Extract portion, theacts of arrows 5-4, 5-6, 5-7, and 5-8 by a Transform portion, and theact of arrow 5-5 by a Load portion of an ETL process caused by thecomputing device executing the Audit ETL package.

Other Embodiments of the Tools

The above sections describe particular examples where the tools auditand find savings for a national bookstore chain. In this section otherembodiments of the tools are described using process 600 of FIG. 6.

This process and the example processes and flow diagrams described orillustrated in FIGS. 2 through 5 may be implemented in any suitablehardware, software, firmware, or combination thereof; in the case ofsoftware and firmware, these processes represent sets of operationsimplemented as computer-executable instructions stored incomputer-readable media and executable by one or more processors (e.g.,processor(s) 110 and computer-readable media 112). These embodiments ofthe tools described in this section are not intended to limit the scopeof the tools or the claims.

Block 602 stores credit-card transaction data and other information,such as interchange categories and their published parameters. Thisinformation may be stored into a rational database in one or moretextual, human-readable formats or in one easily-machine-usable format.In cases were it is stored in more than one format or in a less-desiredformat, it may be transformed into a format designed for consumption bythe tools, such as interchange module 116. The stored credit-cardtransaction data may include any information made available through amerchant-processor statement or made available by a merchant processor,including individual transactions. Examples of this act of storing andvarious types of information and credit-card transaction data, as wellas an example of transforming formats, are set forth above.

Block 604 receives credit-card transaction data from a rational databasefor credit-card transactions accepted through one or more merchantsand/or other information. Each of these merchants may be identified byits own merchant identifier. As noted above, the data may be received byretrieving the credit-card transaction data using an Extract portion ofan Extract, Transform, and Load (ETL) process. This credit-cardtransaction data and other information may be received periodically,such as each calendar month for billing cycles, or historical, such asto build a baseline interchange rate as described above.

The information received may be for multiple merchants, each of themerchants having received customer purchases during a same time period,such as a particular billing cycle, or having batched their respectivecustomer purchases during this period. The merchants can be associatedwith a single client or otherwise. If associated with a single client(e.g., the 2,000 merchants of the national bookstore chain), each may beassociated based on its merchant identifier and a list of merchantidentifiers for that single client.

Block 604 may receive the information based on its merchant identifier,such as all information from merchant-processor statements having aparticular merchant identifier. Thus, the tools may receive,automatically, without user interaction, from a relational database, andusing the merchant identifiers, credit-card transaction data forcredit-card purchases for all merchants of a particular client.

Block 604 may also receive published, merchant-status, andtransaction-status interchange parameters. Here the publishedinterchange parameters may be for each of interchange categoriesassigned and each other type of interchange category to which each ofthe credit-card transactions of a merchant may potentially be correctlyassigned. Examples of these interchange parameters are set forth above.The published interchange parameters may also be non-merchantspecific—instead being based on the parameters of the transactionitself. These transaction-status parameters may include whether or notthe credit card was present at the time of purchase, whether a merchantentered in a ZIP code or taxable status of the purchaser, whether thepurchase was over the internet or phone, whether or not a signature isincluded with the transaction, and whether or not the credit card was abusiness card, to name a few.

After receiving the information at block 604, the tools may proceed toaudit interchange categories assigned or calculate savings since anhistorical period or both. The discussion turns first to auditinginterchange categories (starting at block 606) and then to calculatingsavings (starting at block 612).

Block 606 determines if an interchange category assigned to a particulartransaction or group of transactions is correct. Block 606 may do so forgroups of transactions based on information in a merchant-processorstatement or otherwise made available, such as described in thebookstore example above.

Block 606 may also do so for individual transactions. Determiningcorrect interchange categories for individual transactions may beperformed like groups above, but doing so for individual transactionspermits greater analysis because each transaction may or may not becorrectly assigned based not just on a merchant's status, but also thespecifics of a transaction.

For example, if a particular transaction is assigned a Card Not Presenttype of interchange category and the tools have information about thatparticular transaction, the tools may determine, based ontransaction-status parameters for the transaction, such as the creditcard actually being present at the time of the transaction, that it wasincorrectly assigned.

In some embodiments, block 606 may be performed using an Extract portionof an Extract, Transform, and Load process, such as described above(e.g., ETL 206 of FIG. 2).

Following block 606, the tools may proceed to indicate its findings orproceed to determine a savings or loss based on the incorrect assignmentat block 608. In either case block 610 provides results of the tools'determination, here that one or more transactions have been assigned anincorrect card-issuer interchange category.

Block 608, responsive to the tools determining that an interchangecategory was incorrectly assigned to a transaction or group oftransactions, determines a savings or loss between the incorrectlyassigned interchange-category's rate and the correctinterchange-category's rate. The tools may do so by calculating acorrect fee for the applicable transaction at the correct rate andsubtracting the incorrect fee. The tools may provide this information toblock 610 to report.

The tools may also calculate savings based on reducedinterchange-category rates at blocks 612 to 620. Starting with block612, the tools build a baseline card-issuer interchange rate for amerchant or group of merchants. Block 612 may do so by receivingcredit-card transaction data for multiple historical billing cycles andfor each merchant of a group of merchants, such as those associated witha particular client. The tools may base this baseline rate oncard-issuer interchange fees associated with card-issuer interchangecategories assigned to credit-card transactions and dollar volumes onwhich the card-issuer interchange fees are charged. The card-issuerinterchange fees and dollar volumes can be received from multiplehistoric merchant-processor statements of the particular merchant andover a historical period.

In the bookstore example above, the tools, through interchange module116, extract card-issuer interchange fees and the dollar volumes fromcredit-card transaction data in a relational database and transform thecard-issuer interchange fees and the dollar volumes into the baselinecard-issuer interchange rate by dividing the card-issuer interchangefees by the dollar volumes. In some examples described above, theinterchange module performed these acts automatically using an ETLprocess.

With the baseline determined, block 614 adjusts the baseline card-issuerinterchange rate based on rate changes. Block 614 adjusts the baselinerate based on rate changes made during or after the historical period tothe card-issuer interchange categories assigned to credit-cardtransactions of the particular merchant over the historical period.

In more detail, the tools may receive a rate change to the particularcard-issuer interchange category for the group of credit-cardtransactions assigned to that category, determine a fee change based onthe dollar volume of the group and the rate change, receive or determinea total interchange fee charged during the historical period based on atotal dollar volume and the baseline card-issuer interchange rate, andadd or subtract the fee change for the group from the total interchangefee charged during the historical period. By so doing the tools providean adjusted baseline interchange fee, which the tools divide by thetotal dollar volume to determine an adjusted baseline interchange rate.

In the bookstore example, for instance, the tools adjusted the baselineinterchange-category rate based on an interchange-category's ratechanging from 1.54% and $0.10 per transaction to 1.55% and $0.11 pertransaction.

With the adjusted baseline interchange-category rate available, thetools proceed to block 616. Block 616 determines a current card-issuerinterchange rate for a current billing cycle. The tools may do so bycalculating a card-issuer interchange fee for each of the merchants andthe dollar volume of credit-card purchases for all of the merchants andon which the card-issuer interchange fees charged are assessed. Dividingthe total fee for all merchants by this dollar volume results in acurrent interchange rate averaged over all the merchants.

The tools then determine a rate difference between the adjusted baselineand the current rate at block 618. Block 618 may determine thisdifference automatically by subtracting one from the other.

Block 620 determines a fee savings based on the rate change (if any).The tools may determine this savings, automatically and without userinteraction, based on a credit-card dollar volume for the credit-cardtransactions during the current billing cycle and the determined ratedifference.

Responsive to determining a fee savings at block 620 and/or a feesavings based on an incorrectly assigned interchange category at block608, the tools provide these fee savings at block 610. Block 610 alsoprovides other information and/or performs some calculations. In onecase the tools provide a report, in a human-readable format, showingwhich of the credit-card transactions to which an interchange categoryassigned were not correct and an associated fee savings or loss. Inanother case the tools provide a report to a particular client settingout various fee savings or net savings and a contractually agreed-onpercentage of the fees due.

Each of the above acts involving receiving or retrieving information ofany sort, a calculation (e.g., add, divide, subtract), or enabling thetools to provide results may be performed automatically and without userinteraction, such as through execution of one or more ETL packages.Example ETL packages are described as part of the bookstore exampleabove. The tools, through these ETL packages or otherwise, may providereports to users that compile savings over hundreds of thousands ofcredit-card transactions.

CONCLUSION

The above-described tools are capable of auditing and/or determiningreductions to card-issuer interchange fees charged for credit-cardtransactions. The tools may do so automatically and with userinteraction for thousands or even millions of transactions. By so doing,the tools may permit merchants to track and reduce theirinterchange-category fees without needing extensive manpower orexpertise. Although the tools have been described in language specificto structural features and/or methodological acts, it is to beunderstood that the tools defined in the appended claims are notnecessarily limited to the specific features or acts described. Rather,the specific features and acts are disclosed as example forms ofimplementing the tools.

1. One or more computer-readable storage media having computer-readableinstructions that, when executed by a computing device, cause thecomputing device to perform acts comprising: receiving credit cardtransaction data from a database for credit card transactions associatedwith a particular merchant, the credit card transaction data indicating,for one or more credit card transactions an interchange categoryassigned by a card issuer; receiving published interchange-categoryparameters for the interchange category assigned, the publishedinterchange-category parameters comprising at least one merchant-statusparameter specific to a status of a merchant; receiving a parameterspecific to a status of the particular merchant; and determining,automatically and without user interaction and for the one or morecredit card transactions, whether the interchange category assigned iscorrect based on whether the merchant-status parameter matches thestatus of the particular merchant.
 2. One or more computer-readablestorage media as recited in claim 1, wherein the merchant-statusparameter comprises a business sector, an area of operation, or ataxable or non-taxable status.
 3. One or more computer-readable storagemedia as recited in claim 1, wherein the published interchange-categoryparameters further comprise at least one transaction-status parameter,the acts further comprising: receiving a parameter specific to a statusof the one or more credit card transactions; and determining,automatically and without user interaction and for the one or morecredit card transactions, whether the interchange category assigned iscorrect based on whether the transaction-status parameter matches theparameter specific to the status of the one or more credit cardtransactions.
 4. One or more computer-readable storage media as recitedin claim 3, wherein the transaction-status parameter comprises at leastone of an indication of whether a credit card is present or not presentat the time of a transaction, an indication of whether a signature isincluded with a transaction, an indication of whether a credit card is abusiness card or a personal card, an indication of whether a tax code isincluded with a transaction, or an indication of whether a ZIP code isincluded with a transaction.
 5. One or more computer-readable storagemedia as recited in claim 1, wherein the database comprises a relationaldatabase.
 6. One or more computer-readable storage media as recited inclaim 1, wherein said act of receiving credit card transaction dataretrieves the credit card transaction data using an Extract portion ofan Extract, Transform, and Load (ETL) process, and the act ofdetermining uses a Transform portion of the ETL process.
 7. One or morecomputer-readable storage media as recited in claim 6, furthercomprising presenting the results of the act of determining using a Loadportion of the ETL process.
 8. One or more computer-readable storagemedia as recited in claim 1, further comprising, prior to the act ofreceiving the credit card transaction data: extracting text-format,pre-transformation credit card transaction data; transforming thetext-format, pre-transformation credit card transaction data into datain a machine-usable format; and loading the data in the machine-usableformat into the database, wherein the act of receiving the credit cardtransaction data receives the credit card transaction data in themachine-usable format.
 9. One or more computer-readable storage media asrecited in claim 1, wherein the act of receiving comprises receivingcredit card transaction data for multiple merchants, each of themultiple merchants and the particular merchant: having a merchantidentifier; having received or batched customer purchases during a sametime period; and being associated with a single client through theirrespective merchant identifiers.
 10. One or more computer-readablestorage media as recited in claim 1, wherein the one or more credit cardtransactions are transacted with branded credit cards or processedthrough a network associated with a branded credit card.
 11. One or morecomputer-readable storage media as recited in claim 1, furthercomprising determining, automatically and without user interaction, forthe one or more credit card transactions, a correct interchange categoryfor the one or more credit card transactions based on othermerchant-status parameters for another interchange category matching theparticular merchant's status.
 12. One or more computer-readable storagemedia as recited in claim 1, wherein said determining comprisesdetermining that the interchange category assigned is incorrect, theacts further comprising providing a report, in a human-readable format,indicating that the one or more credit card transactions were assignedan incorrect interchange category.
 13. One or more computer-readablestorage media as recited in claim 1, wherein said determining comprisesdetermining that the interchange category assigned is incorrect, theacts further comprising determining a savings for the one or more creditcard transactions by determining a correct fee for a correctinterchange-category and subtracting the correct fee from a fee chargedbased on the interchange-category incorrectly assigned.
 14. Acomputer-implemented method, comprising: building, automatically andwithout user interaction, a baseline card-issuer interchange rate for aparticular merchant based on: card-issuer interchange fees associatedwith card-issuer interchange categories assigned to credit cardtransactions; and dollar volumes on which the card-issuer interchangefees are charged, the card-issuer interchange fees and dollar volumesbeing from multiple historic merchant-processor statements of theparticular merchant and over a historical period; adjusting,automatically and without user interaction, the baseline card-issuerinterchange rate for the particular merchant based on interchange ratechanges made after the historical period to the card-issuer interchangecategories assigned to credit card transactions of the particularmerchant over the historical period, effective to provide an adjustedbaseline card-issuer interchange rate; receiving, automatically andwithout user interaction, credit card transaction data for a currentbilling cycle for credit card transactions associated with theparticular merchant, the credit card transaction data being used todetermine card issuer interchange categories currently assigned to thecredit card transactions during the current billing cycle; determining,automatically and without user interaction, a current card-issuerinterchange rate for the current billing cycle based on the card issuerinterchange categories assigned during the current billing cycle;determining, automatically and without user interaction, a ratedifference between the card-issuer interchange rate for the currentbilling cycle and the adjusted baseline card-issuer interchange rate;determining, automatically and without user interaction, a fee savingsor loss based on a credit card dollar volume for the credit cardtransactions during the current billing cycle and the determined ratedifference; and providing an indication of the fee savings or loss to anentity associated with the particular merchant.
 15. Thecomputer-implemented method of claim 14, wherein the method is performedfor different merchants, the different merchants and the particularmerchant being associated with a particular client, and wherein themethod further comprises providing, in a human-readable format and formerchants of the particular client, an indication of the fees saved anda payment due, the payment due being based on the fees saved and apercentage of the fees saved.
 16. The computer-implemented method ofclaim 14, wherein the act of building the baseline card-issuerinterchange rate comprises: extracting the card-issuer interchange feesand the dollar volumes from a relational database; and transforming thecard-issuer interchange fees and the dollar volumes into the baselinecard-issuer interchange rate by dividing the card-issuer interchangefees by the dollar volumes.
 17. A computer-implemented method,comprising: receiving credit card transaction data associated with aparticular merchant, the credit card transaction data including anindication of at least one credit card transaction assigned to aninterchange category; determining whether the at least one credit cardtransaction was correctly assigned to the interchange category bycomparing a status of the merchant with a merchant-status parameter usedto assign the at least one credit card transaction assigned to theinterchange category; and reporting an indication of whether the atleast one credit card transaction was correctly assigned to theinterchange category.
 18. The computer-implemented method of claim 17,wherein the merchant-status parameter comprises at least one of abusiness sector, an area of operation, or a taxable or non-taxablestatus.
 19. The computer-implemented method of claim 17, wherein saiddetermining comprises determining that the at least one credit cardtransaction was incorrectly assigned to the interchange category, themethod further comprising determining a savings for the at least onecredit card transaction by determining a correct fee if the at least onecredit card transaction is assigned to a correct interchange category,and subtracting the correct fee from a fee charged based on theinterchange category incorrectly assigned.
 20. The computer-implementedmethod of claim 17, wherein the at least one credit card transaction isincluded as part of a batch of multiple credit card transactions, andwherein the method is performed automatically on each of the multiplecredit card transactions.